Skip to main content

Getting Started Guide

Obtain API Key​

  1. Contact DIDx at [email protected] to inquire about obtaining OAuth 2.0 Client Credentials.

  2. Provide DIDx with any necessary information they require to generate Client Credentials, such as your name, email address, and a description of what you plan to use the SaaS API key for.

  3. DIDx will then generate OAuth 2.0 Client Credentials for you and provide it in a JSON format, such as:

    { "ClientID": "ClientID", "ClientSecret": "ClientSecret" }

  4. Copy the provided OAuth 2.0 Client Credentials from the JSON format and store it in a secure location for future use.

  5. Use the OAuth 2.0 Client Credentials to authenticate against the OAuth 2.0 Access Token URL to get a valid token.

    https://cloudapi.test.didxtech.com/oauth2/token

  6. Once a token is received it should be passed as an Authorization header as follows:

    { "Authorization": "Bearer <Token>" }

Resources​

CloudAPI Swagger:

OpenAPI Document:

Indy Ledger:

* Authorization bearer token needed to view these pages

Authentication​

Authentication is handled by CloudAPI, and from a client perspective it's kept simple and convenient. Either, via the Swagger UI auth (padlock button in UI) or via the header data of your client specifying an x-api-key or Authorization: Bearer <Token>.

When acting as tenant-admin on CloudAPI-Multitenant-Admin, regardless of whether you use the UI or another client, the Authorization: Bearer <Token> needs to be passed.

"Authorization": "Bearer <Token>"

When acting as a tenant on CloudAPI-Tenant, regardless of whether you use the UI or another client, the x-api-key value consists of two parts, separated by a dot:

    x-api-key: tenant.{token}

This would look like, e.g. 'x-api-key: tenant.eyJhbGcjE...3MDcjnK9PKGY' (JWT token).

The first part, tenant a.k.a the role, specifies the role on the surface and targets the correct endpoints and authentication mechanisms under the hood. CloudAPI knows how to interpret the roles and will produce the correct target URLs; for example, tenant targets the multitenant agent, with the correct header expected by the ACA-Py agent.

Governance and tenant-admin are privileged admin roles, while the rest are non-admin, meaning they have no exposure to ACA-Py admin tasks or any documented endpoints prefixed with admin in the CloudAPI.

Currently, there are three availables roles:

CloudAPI Roles​

Governance Role (DIDx)​

  • governance
    • is:
      • trust authority
      • transaction endorser
    • can:
      • make connections
      • create schemas
      • create credential definitions
      • manage trust registry
      • issue credential
      • verify credential
      • send basic messages

Tenant Administration Role​

Authentication header example: 'Authorization': 'Bearer < Client-token >'

  • tenant-admin
    • is:
      • trust ecosystem admin
      • is transaction author
    • can:
      • only create, update, and delete tenants (wallets) for trust ecosystem issuers, verifiers, and users

Tenant Role (Trust Ecosystem Issuers, Verifiers, and Holders)​

Authentication header example: 'x-api-key: tenant.ey..'

  • tenant
    • is:
      • holder
      • issuer and/or verifier
    • if is issuer or verifier
      • issuers are transaction authors
      • verifiers are not transaction authors
      • automatically registered with the trust registry
      • can:
        • make connections
        • create credential definitions
        • issue credential
        • create/manage wallets
        • all transactions written to the ledger are counter-signed by the governance transaction endorser role
    • if is user (holder):
      • holder only
      • can:
        • make connections
        • manage own wallet (holder)
        • receive and store credentials
        • respond to/create proof request
        • send basic messages
        • view their webhooks events